Rob Collins - DumbDev -- eight rules for dumb development
[EuroPython 2015]
[24 July 2015]
[Bilbao, Euskadi, Spain]

So often, we've been encouraged to be smart in our development. "Work
smarter not harder!" say the encouraging posters. But the desire to be
smart, and be seen to be smart, is hurting. The design suffers, the
code suffers, and it's hard to recruit developers smart enough to cope
with the problems caused.

In this talk, I'm proposing an alternative to being smart:
**_DumbDev_**. Let's use our brains for enjoyable, interesting things,
rather than wrestling with code written for smart developers.

**So what do I mean by _dumb_?**

Well, I don't mean 'ignorant'. A clever person can be ignorant of some
important information, and learn it. With ignorance, there is hope.
I'm also not talking about its opposite, 'stupidity'. This occurs when
someone is given the information or advice, and chooses to ignore it.
Dumb isn't stupid. Nor is it silent, as in someone who can't speak.

Instead, the picture I have is of one of the early computers: very
small RAM, disk space measured in KB, and a woefully inadequate CPU.
In other words, slow, with very little working memory and limited
persistent storage. Hey, this describes my brain -- and I realise
that's an asset! I will write better software if I take this into
account.

So, I'm a **_DumbDev_**, which means I can't hold in my mind the
infamous [Plone Site class hierarchy][1] (see [Michele Simionato's
article][2]). Rather than beat myself up about this, I can say, "Hold
on, maybe deep inheritance is a bad idea..." There is some debate
about the number of things we can think about simultaneously: it may
be 7, 9, 5, 4 or even only 3. We can learn some tricks to appear to
cope with more, but most of us can't easily do 38.

Here's the first **_DumbDev_** rule, putting a sensible limit on complexity:

> **1. All diagrams must fit on a Noughts and Crosses (Tic-tac-toe) board**.

> _One central class/concept and up to eight things linked. Larger
structures need to be subdivided._

There are seven further rules for me to explain in this talk. I will
demonstrate the benefits of the **_DumbDev_** approach, with good and
bad examples. At the end of the presentation, I hope you will realise
that you're a better developer than you thought at the start. The next
time it takes you two hours to debug a simple exception, you'll know
that it's not you. It's because the system wasn't written using
**_DumbDev_** rules.

Let's free our brains for more interesting things, like having ideas
and solving problems.

Let's do **_DumbDev_**.

[1]: http://www.phyast.pitt.edu/~micheles/python/plone-hierarchy.png
[2]: http://www.artima.com/weblogs/viewpost.jsp?thread=246341

plus-circle Add Review

comment

Reviews